• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to a method for securing a payment token, a mobile terminal (12) and a server (11) for generating a payment token. The method comprises a prior step of pairing a subscriber's terminal identifier and a personal password with a payment instrument (17), then a step of generating a secure payment token (104) with the username and the personal password. The pairing and the generation of the secure payment token (104) makes it possible to verify that the token (103) is used by the subscriber and by his mobile terminal (12). The invention applies to payment token payment systems with usage restrictions.
    公开号:FR3028639A1
    申请号:FR1461087
    申请日:2014-11-17
    公开日:2016-05-20
    发明作者:Eric Lassouaoui；Philippe Ledru；Francis Limousy
    申请人:Oberthur Technologies SA；Oberthur Technologies of America Corp；
    IPC主号:
    专利说明:

    [0001] The field of the invention relates to a method of securing a payment token derived from a payment instrument, a mobile terminal and a payment token generating server. Fraud à la carte payment are still existing despite the sophistication of securing bank data on the payment and verification 10 of a transaction by the payment network. A payment card is protected by a verification of a personal code stored in an electronic chip as well as the use of dynamic algorithms for the verification of the data of the bank transaction. With the development of the digital economy, the share of transactions carried out on the Internet is increasing day by day. A new trend is also the integration of virtual payment card hosted on a mobile payment application of a mobile phone. An underwriter thus has a dematerialized version of his bank card that he can use for a near field payment using the NFC (Near Field Contact) technology. This new economy is an opportunity for banking institutions but also presents risks of 25 significant fraud due to the exposure of bank data, including the credit card number, the security cryptogram and the date of validity of the card. The refractors to the near-field payment technology denounce in particular the vulnerability of the bank data 30 during the near-field communication because the data are transmitted without encryption. In particular, there are data interceptors that can be used in a transaction. Moreover, it is not uncommon for hackers to steal banking data from the server 5 of an online merchant. In response to these bank frauds, banking institutions are looking for solutions to not expose the banking data of a bank card subscriber. There are now systems for hosting banking data on secure bank servers and solutions for generating restrictive payment tokens (in English) which are derived from the payment card of a bank. subscriber. These tokens are restrictive in the sense that they may include use restrictions, for example being valid for a limited period of time, with a single merchant or capped at a maximum transaction amount. These payment solutions are designated by HCE for "Host Card Emulation" in English. In case of theft of the token data, the financial exposure is reduced. An HCE architecture requires a card-based token generation server by diversification algorithms, remote token provisioning servers on a banking application hosted on the operating environment of a portable terminal (cellular telephone). or tablet for example) and a token verification server capable of determining the bank data of a subscriber corresponding to the payment token. In this architecture, a subscriber of a bank card may have a bank card in various forms, a physical chip or magnetic stripe card, a virtual card housed in an electronic purse on his mobile phone (commonly called Mobile Wallet ") or a virtual card hosted on a remote server (commonly called" Cloud Wallet "). US patent application US20130200146A1 is known describing a hosting solution on a remote server of a virtual bank card. Nevertheless, even if a payment token has usage restrictions, it remains exposed to theft between the time it is provisioned on a mobile phone and the time of its use. Indeed, the subscriber can plan to provision on his phone a batch of chips for multiple payments. In addition, telephone manufacturers and banking institutions wish to offer electronic wallets on a mobile phone without the constraints of a secure chip and to offer a fully software payment solution. Such a solution is particularly exposed to data theft. There is therefore a need to find new security measures for payment tokens on a mobile phone, especially when the tokens are hosted outside a secure chip. More specifically, the invention relates to a method for securing a first token derived from a payment instrument of a subscriber that can be hosted in a mobile terminal by a payment application. According to the invention, the method comprises the following successive steps: - the pairing on the one hand of an identifier of the mobile terminal and the payment instrument and on the other hand a personal cryptogram and the payment instrument, - the provision of the first token to the payment application 5, - the receipt of data of a payment transaction by the payment application, - the generation of a second secure payment token by the encryption at least the first token, the transaction data, the terminal identifier and the personal cryptogram. More specifically, the pairing is operated following a successful authentication protocol between the payment application and a remote authentication server.
    [0002] According to a variant, the pairing is performed when the payment instrument is registered in the payment application. According to one variant, the first token is a random datum derived from a datum representing the bank account number attached to the payment instrument. According to one variant, the encryption of the first token is executed by means of a temporary key received from a server for generating the payment token. Alternatively, the method further comprises generating the terminal identifier and the personal cryptogram by the payment application, the generation being initiated by receiving the transaction data. According to one variant, the generation of the identifier of the terminal and the personal cryptogram by the payment application comprises the reading in a secure memory of the terminal conditioned on the entry of a personal password or in another variant. execution of a cryptographic calculation conditioned to the entry of a personal password. According to one variant, the generation of the identifier of the terminal and the personal cryptogram by the payment application is triggered by an authentication request from the subscriber during the payment transaction, the payment transaction being a payment transaction without contact in accordance with ISO / IEC 14443. Preferably, during the execution of the banking transaction, the identifier and the personal cryptogram are stored in a volatile memory of the terminal.
    [0003] It is expected that the provisioning of the first token comprises the writing of the first token in a non-volatile memory of the terminal. According to the invention, there is provided a mobile terminal comprising a payment application comprising a processing agent of a first token derived from a payment instrument of a subscriber and a means of receiving data of a payment transaction. The payment application further comprises: means for pairing an identifier of the mobile terminal and a personal cryptogram with the payment instrument, and the token processing agent includes a means for generating the a second payment token secured by the encryption of at least the token, the transaction data, the identifier of the mobile terminal and the personal cryptogram.
    [0004] Alternatively, the payment application further comprises means for generating the identifier of the mobile terminal and the personal cryptogram by the payment application.
    [0005] It is also envisaged that the invention relates to a server for generating a first token comprising means for generating a first token derived from a payment instrument of a subscriber, characterized in that it also comprises A means for pairing an identifier of the mobile terminal and a personal cryptogram of the subscriber with the payment instrument; means for verifying a second secure payment token generated by the encryption of at least the first token, transaction data, the mobile terminal identifier and the personal cryptogram. According to one variant, the identifier of the mobile terminal and the personal cryptogram of the subscriber are received from an authentication server.
    [0006] Alternatively, the first token is generated by means of a random generator based on at least one data item representing the bank account number attached to the payment instrument. Thanks to the invention, the use of the payment token is secured by prior pairing with the user, via a personal cryptogram, and with his mobile terminal, registered by a unique identifier. The integration of the terminal and user identification data enables the verification server of the bank transaction to verify that the token has been used by the registered terminal and the user.
    [0007] Other features and advantages of the present invention will become more apparent upon reading the following detailed description of embodiments of the invention given as non-limiting examples and illustrated by the accompanying drawings, in which: : Figure 1 represents the ecosystem of an HCE payment architecture. Figure 2 illustrates the mobile software operating environment for hosting and generating a secure payment token. Figure 3 shows a stream of sequences for pairing a user and a mobile terminal prior to provisioning and generating a payment token to the subscriber.
    [0008] FIG. 4 shows a flow of sequences during the execution of a bank transaction and the generation of a secure payment token. The invention applies as part of a payment system provisioning a subscriber of a payment instrument with secure payment tokens. This payment system is commonly referred to by the acronym HCE and the payment tokens are referred to as "payment token" in English. Figure 1 shows the ecosystem of an HCE payment solution. It provides for a banking entity 16, a bank or a payment service, which can issue a payment instrument 17. The payment instrument 17 may comprise several payment products in the form of a bank card or a service online payment via an internet portal or a payment service by means of 3028639 8 payment tokens that can be provisioned to a mobile terminal 12 of the subscriber. The payment instrument 17 is defined: by the subscriber's bank data, such as an account number attached to the payment instrument and personal data, by criteria for the use of the payment instrument, in particular a validity period, a geographical area, a transaction limit, 10 - and by security data, such as for example the security cryptogram or electronic security mechanisms embedded in a payment card for verifying the data of a security card. Bank transaction. In the case of a mobile terminal 12 intended to receive payment tokens, the security mechanisms can be hosted in a secure module welded in the terminal, for example an NFC type integrated circuit, or be hosted at the level of a secure environment (called TEE, for "Trusted Execution Environment"). In the latter case, this is a fully software solution in which the application area of the operating environment of the mobile terminal executing a payment application is considered to be trusted by various security mechanisms. These mechanisms may be the verification of the memory zone, or authentication protocols with a remote authentication server 10 for the installation of applications or payment profiles. Next, the functions of the mobile terminal 12 which can generate the secure payment token 104 used in the context of the invention will be studied in greater detail.
    [0009] Preferably, the mobile terminal 12 comprises communication means for receiving and transmitting data remotely via the cellular telephone network, an IP type data network via the telephone network or an IP type data network via a network. medium range network, for example WIFI. In the context of the invention, there is provided an authentication server 10 managed by the banking institution 16 or by a third party authentication services operator. The authentication server 10 exchanges cryptographic means 102 with the mobile terminal 12. These cryptographic means 102 are, for example, session cryptographic keys, temporary transaction numbers or cryptographic algorithms making it possible to operate an encryption protocol. secure exchange. These cryptographic means are exchanged via a secure channel that can be an HTTPS ("Hyper Text Transfer Protocol Secure"), CAT TP ("Card Application Toolkit Transport Protocol") or SMS ("Short 20 Message Service") communication protocol. Furthermore, the authentication server 10 can exchange information with the banking entity 16 via a secure wireless remote data communication network or via a wired communication network if the authentication server 10 is operated by the remote control. banking entity 16. Thus, the banking entity 16 can transmit a subscriber's personal and banking data to the authentication server 10 for the purposes of the authentication protocols between the subscriber's mobile terminal 12 and the subscriber server. authentication. A server 11 for generating tokens 103 derived from the payment instrument 17 is also provided. The server 10 includes cryptographic means for generating a token 103 from bank data 105 attached to the payment instrument 17. A random data generator may generate a token 103 from the bank data 105 and from a bank. means of diversification or diversion, for example a meter. Other means of diversification can be implemented for the generation of the token 103 in the server 11. It will be noted that it is expected that the bank data 105 used by the random data generator can be retrieved by the server 11. generation of tokens or by a partner verification server on the basis of the information of the secure payment token 104. The bank data are thus protected and kept secret in the 15 of the server 11. Furthermore, the token generation server 11 can exchange information with the banking entity 16 via a secure wireless remote data communication network or via a wired communication network if the authentication server 11 is operated by the banking entity 16. Thus, the entity bank 16 can transmit a subscriber's personal and banking data to the authentication server 10 for the purposes of the self protocols. authentication between the mobile terminal 12 of the subscriber 25 and the authentication server. In addition, the token generation server 11 may exchange information with the authentication server 10 via a secure wireless remote data communication network or via a wired communication network if the servers 10 and 11 are in management. by the same operator. The authentication server 10 exchanges cryptographic means 101 with the generation server 11 of 10 chips 103. These cryptographic means 101 are for example session cryptographic keys, temporary transaction numbers or cryptographic algorithms for operating a secure exchange protocol with the terminal 12. The secure exchange protocol with the terminal 12 allows in particular to exchange tokens 103 via a secure channel that can be a communication protocol HTTPS, CAT TP or SMS.
    [0010] A secure payment network 15 may be provided for transmitting subscribers' bank data and banking transaction data compliant with EMV standard specifications, for example, conventional transaction data and secure payment tokens. The secure payment network 15 is operated by a payment service operator 14 responsible for carrying out payment banking transactions. The payment service operator uses the secure network 15 to transmit the transaction data received from the merchants 13, by means of a payment terminal or a remote payment server. The network 15 uses a secure wireless or wired communication network between the payment terminals. Figure 2 further describes the terminal 12. It includes a payment application 24, hosted by the operating environment of the mobile terminal 12 or in a secure module, for example eUICC (for "Embedded Universal Integrated Circuit Card"). The mobile terminal 12 comprises non-volatile memories, of the ROM type ("Read Only Memory" in English, EEPROM (Elecrtically Erasable Read Only Memory) or FLASH for the recording of parameters and the code of execution of applications. and the computer program comprising the instructions for implementing the method of securing the payment tokens, for example the operating environment of the terminal, applications or libraries of specific functions that can be used by the applications. comprises in particular function libraries, classes or methods, called APIs for "Application 10 Progamming Interface" in English, for exchanges with the chip generation server 11, for the execution of payment transactions with a payment terminal 13 and for authentication with the authentication server 10. The application 24 can use the functions provided by the APIs. The mobile terminal also comprises a RAM (Random Acess Memory) for the recording of temporary parameters, for example bank transaction data or a secure payment token 104. The RAM comprises registers adapted for recording the variables and parameters created during the execution of the computer program including the instructions for implementing the method of securing the payment tokens during its execution.
    [0011] The terminal 12 furthermore comprises human-machine interfaces for entering and displaying data with the subscriber, for example for entering a personal code (PIN code in English, "Personal Identification Number") and for Interaction with the payment application 24. It is expected that the payment application will display requests on a screen of the mobile terminal, for example a request to approach the terminal 12 of the payment terminal 13, a request for payment. entering a personal code or a request to choose a payment instrument. The mobile terminal comprises the calculation processor for executing the functions of the applications of the mobile terminal 12. The payment application 24 comprises a processing agent 23 of a token 103 derived from a payment instrument 17 of a subscriber and means of receiving data from a payment transaction. The processing agent 23 is a function of the payment application 24 enabling the receipt of the token 103 sent from the token generation server 11 and its storage in a non-volatile memory of the mobile terminal. The processing agent 23 is a software application exploiting the APIs software functions making it possible to interact with the generation server 103 of the token 103. Moreover, the payment application 24 hosts one or more payment instruments 17. A card The payment virtual is stored as an application specific to the payment card profile and can be stored by means of an application identifier. The payment instrument is recorded in the payment application prior to the first provisioning of a payment token. The bank transaction data receiving means 25 is a function of the payment application 24 enabling communication with the payment terminal 13. The receiving function is capable of controlling a contactless exchange protocol according to the ISO standard. / IEC 14443, to record the transaction data in a memory 30 and to return responses to the payment terminal 13.
    [0012] In addition, the payment application 24 includes a pairing means 26 of an identifier of the mobile terminal 22 and a personal cryptogram 21 with the payment instrument. This is a function that uses software functions APIs for authentication with the authentication server 10 and the token generation server 11. The pairing includes means for generating the identifier 22 assigned to the terminal 12 and the personal cryptogram 21 assigned to the subscriber.
    [0013] The identifier of the terminal 22 may be generated by the authentication server 10 and be transmitted to the terminal 12 to be registered in a secure manner, for example encrypted by means of a key. In another variant, the identifier 22 may be the IMEI number ("International Mobile Equipment Identity" in English) of the terminal 12 and be transmitted to the authentication server 10. It may be transmitted by the terminal 12 during the pairing or by the banking entity 16. The personal cryptogram 21 may be a password, a personal code, or a digital biometric fingerprint known to the subscriber and the authentication server. The personal cryptogram can also be generated by a function following successful PIN authentication or biometric authentication. Alternatively, the personal cryptogram 21 may be generated from a known random only of the terminal 12 and the authentication server or an encryption key. Known methods known as salting also make it possible to generate the personal cryptogram 21 by both the payment application 24 and by the authentication server 10 at the same time.
    [0014] The pairing is effective when the payment application 24 has linked a payment instrument 17 with the identifier 22 of the terminal and the personal cryptogram 21.
    [0015] Similarly, the generation server 11 links the identifier 22 and the cryptogram 21 with the payment instrument 17. The identifier 22 of the terminal 12 and the personal cryptogram 21 allowing the pairing in the server 11 are transmitted by 5. the authentication server 10, which has previously passed the authentication protocol with the terminal 12 and the subscriber. Pairing is preferably performed upon registration of the payment instrument 17 in the mobile terminal. The registration corresponds to the installation of a digital payment profile in the non-volatile memory of the mobile terminal 12. The pairing of the terminal is secured by authentication with the authentication server 10.
    [0016] In addition, the processing agent 23 of a token 103 comprises means for generating a secure payment token 104 by the encryption of at least the token 103, the transaction data, the identifier 22 of the terminal mobile and the personal cryptogram 21. A token encryption key 20 and an encryption algorithm of the HMAC (for "keyedhash message authentication code") type, for example in accordance with the OATH recommendations ("Initiative for Open Authentication"), are used to execute the encryption and obtain the secure payment token 104.
    [0017] The encryption algorithm allows mutual authentication with the token generation server 11. The encryption key is transmitted to the payment application 24 by the token generation server 11. The key is stored in a secure area of the mobile terminal, encrypted or not when not in use. The encryption key can be temporary. It can be associated with a single payment token 103, a lot of payment token 103 or be time limited. More specifically, the data of the token 103, the transaction data of the payment terminal 13 (amount of the transaction, transaction number), the identifier 22 of the terminal and the personal cryptogram 21 are concatenated in a data block (which can for example, to reach 128 bits). This concatenated data is then encrypted by the encryption algorithm using the encryption key.
    [0018] The secure payment token 104 generated by the payment application 24 is in the form of a cryptogram accompanying a verification request of a bank transaction comprising at least the transaction data. Note that the generation of the secure payment token 104 can be operated offline, ie a connection to the token generation server 103 is not necessary during the transaction. In addition, the processing agent 23 includes means for inserting the secure payment token 104 into a conventional banking transaction protocol. It can be inserted in a standardized data field in EMV transaction protocols ("Europay Mastercard Visa", registered trademarks) for example. Thus, the secure payment token 104 can be transmitted by a payment terminal without modification of its communication protocol with the payment network 15. The generation server 11 of a token 103 comprises means for generating a token derivative of the payment instrument 17. The derived token is a random item. The token 103 is generated from the bank data 105 of the payment instrument 17 (associated account number) and a diversifying 3028639. The diversifier represents an authorization for a payment transaction with usage restriction criteria determined by the server 11, for example a validity for one or more banking transactions, a time validity, a validity for a transaction ceiling. In the context of the invention, the server 11 also comprises a means of pairing the identifier of the mobile terminal 22 and the subscriber's personal security code 21 with the payment instrument 17. It comprises in particular in its 10 databases. bank data, the bank data 105 associated with the payment instrument 17 (associated account number), and the identifier 22 of the terminal 12 and the personal cryptogram 21 of the subscriber which are allocated to the payment instrument 17.
    [0019] In addition, it comprises a means for verifying the secure payment token 104 generated by the encryption of at least the token 103, transaction data, the identifier 22 of the mobile terminal and the personal encryption device 21. It notably comprises the complementary cryptographic means than those of the payment application 24 for generating a second payment token for verification purposes, depending on the transaction data transmitted by the verification request of a bank transaction. The verification means comprise means for generating a verification cryptogram by the encryption of at least the token 103, the transaction data, the identifier 22 of the mobile terminal and the personal cryptogram 21. A comparison of the token of secure payment 104 with the verification cryptogram allows the transaction to be authorized or not. Note that the identifier of the mobile terminal 22 and the subscriber's personal cryptogram 21 are received from the authentication server 10 or can be generated dynamically upon receipt of the secure payment token 104 for verification of the bank transaction. FIG. 3 represents a flow of sequence sequences 5 for the pairing of a payment instrument with an identifier 22 of the terminal 12 and a personal cryptogram 21. The pairing is performed when the payment instrument 17 is registered. in the payment application 24 of the subscriber terminal 12.
    [0020] At a step 31 of the registration request, the subscriber via his payment application 24 proceeds to register it for the use of the payment instrument 17. The registration request is transmitted to the banking entity 16 operator of the payment instrument. the payment instrument.
    [0021] As a variant, the registration request step 31 can be carried out via a web portal, or directly to the agency of the banking entity. The banking entity 16 initiates a registration request in a step 32. In step 32, identifiers and a one-time personal password can be generated and transmitted to the subscriber to initiate authentication with the server. In parallel, the identifiers and password are communicated to the server 11 for generating a payment token 25 during a step 33 and then to the authentication server 10 during a step 34. step 33, the banking entity 16 also transmits the banking data of the payment instrument 17 allowing the realization of a payment (bank account number and restriction criteria in particular).
    [0022] In step 35, the authentication server 10 initiates an authentication protocol waiting to receive a pairing request from the payment application 24 of the user. Encryption key sets and authentication transaction identifiers are prepared to allow secure transmission of a terminal identifier and personal cryptogram between the payment application and the authentication server. During a step 37, the payment application 24 10 initiates a pairing request and executes the decryption and encryption operations necessary for carrying out the requests and responses involved in the authentication protocol 36. In parallel, the server 10 In step 38, the user performs the additional operations for performing the authentication protocol for the pairing 36 between an identifier of the mobile terminal and the payment instrument and a personal cryptogram of the subscriber and the payment instrument.
    [0023] In a variant, the authentication protocol may be initiated by the authentication server towards the payment application 24. During the authentication protocol corresponding to the execution of the pairing 36, the identifier 22 of the terminal 12 and the personal cryptogram 21 are generated either by the server 10 or by the payment application 24 and exchanged mutually. It will be noted that the pairing 36 comprises the storage of the identifier 22 of the terminal and the personal cryptogram 21 30 in the authentication server 10 or the storage of calculation functions for the generation of the identifier 22 of the terminal 20 and the terminal. Personal encryption 21 in the authentication server 10. In a variant, the identifier 22 of the terminal and the personal cryptogram 21 are generated dynamically during each bank transaction. The payment application 24 and the server 10 have generation means that are exchanged during the authentication phase 36. This may be a specific authentication application and the cryptographic algorithms. These means for generating the identifier 22 and the personal cryptogram 21 may also be obtained via an application portal or may already be installed with the payment application 24. The payment application 24 is installed via a payment protocol. secure installation comprising the installation of a profile of a banking application in an NFC secure module for the transaction of banking transactions in accordance with ISO / IEC 14443. When the authentication protocol, for the pairing operation 36, terminates successfully, in a step 39, the authentication server 10 communicates to the payment token generation server 103 the terminal identifier 22 and the personal cryptogram 21 among the cryptographic means 101. for verification of payment transactions using payment tokens. In step 40, the server 11 installs the identifier 22 of the terminal and the personal cryptogram 21 or the generation means associated with the payment instrument 17 of the subscriber.
    [0024] In step 41, the banking entity 16 is informed of the success of the authentication and pairing for the operation of the payment solution by means of secure payment tokens. Figure 4 shows a sequence flow when generating a secure payment token 104 during a bank transaction. At a first step 50, the payment application 24 proceeds with a request for provisioning a token. An authentication step of the subscriber is performed with the authentication server 10. By verifying a personal identifier and password, or alternatively by means of the identifier 22 of the terminal 12 and the personal cryptogram 21 generated. during the pairing step. If the authentication is successful with the authentication server 10, the application 24 operates in a step 51 15 a request for provisioning a token 103 to the server 11 generating token. The provisioning request is made via a secure communication channel between the payment application 24 and the server 11, for example an HTTPS, CAT_TP or SMS communication protocol. In step 52, the token generation server 11 generates a first token 103 derived from the payment instrument 17. The token 103 is a random data item derived from a data item 105 representing the bank account number 25 attached to the payment instrument. the payment instrument 17. This data may be the bank account number. The token 103 is a random data item defined by usage restriction criteria, for example a bank transaction number, a period of validity or an amount of the transaction. A random generator function of at least the data item 105 representing the bank account number attached to the payment instrument 17 is preferably used. A counter providing an input data to the generator makes it possible to diversify the data item 105. At a step 53, the server 11 transmits the token 103 to the payment application 24 via the same secure channel used during the step 51. At a step 54, the payment application 24 stores the token 103 in a secure memory zone (non-volatile) of the mobile terminal 12. The processing agent 23 stores the token 103 in a memory zone whose access is conditioned in an authentication with the authentication server 10. In a variant, the token 103 is transmitted encrypted pending use by means of a key provided by the server 11. In a step 55, a banking transaction protocol is initiated with a payment terminal 13. The application 24 receives transaction requests and issues responses to these requests. The transaction is a NFC contactless payment transaction in the near field, for example in accordance with ISO / IEC 14443. During a first exchange, transaction data may be transmitted, for example a transaction amount. At a step 56, the payment application 24 proceeds to the generation of the identifier 22 of the terminal and the personal cryptogram 21. The generation can be a reading in a secure memory of the terminal 12 or the generation of the data by calculations. cryptographic, for example a decryption or encryption. The generation 56 is preferably conditioned on entering and verifying a personal password (PIN code, sentence, reading a biometric fingerprint type data or reading the iris).
    [0025] During the generation 56, the identifier 22 and the cryptogram 21 may be stored in a volatile memory of the terminal 12 during the execution of the bank transaction. After, the realization of the banking transaction, they are then erased so as not to be exposed to possible fraudsters. It will be noted that the generation 56 of the terminal identifier 22 and the personal cryptogram 21 can be triggered by an authentication request from the subscriber during a contactless payment transaction, in accordance with the ISO / IEC 14443 standard. step 57, the payment application 24 operates the generation of a second secure payment token 104. The payment application 24 encrypts at least 15 the first token 103, the transaction data, the identifier 22 of the terminal and the personal cryptogram 21. The application 24 uses the encryption algorithm of the token processing agent 23 to generate the secure payment token 104. The encryption algorithm therefore makes the token secure payment method 104 unique per terminal 12 and unique per subscriber. If the payment token 104 is used by another terminal, which has not been registered during the pre-pairing and is not able to reproduce the terminal identifier 22, the server 11 of the token check secure payment 104 can detect the situation and refuse the bank transaction. Similarly, if the payment token 104 is used by another subscriber, which has not been registered during the pre-pairing and is not able to reproduce the personal cryptogram 21, the verification server 11 of the 3028639 24 secure payment token 104 can detect the situation and refuse the bank transaction. Optionally, the format of the secure payment token 104 may be modified, for example by a hash function 5, to be inserted in a data field conforming to a bank transaction. Then, in a step 58, the secure payment token 104 is transmitted to the payment terminal 13 during the execution of the bank transaction. It is transmitted in the near field via the NFC communication means, accompanied by data from the banking transaction, as conventionally operated in the EMV standard. The payment terminal 13 then transmits the secure payment token 104 to the generation server of the payment token 103 for purposes of verifying the transaction via the payment network 15. The verification server 11 may be separate from the server 11 Token generation. It may be expected that the same subscriber will pair with a second mobile terminal, for example a multimedia tablet if the first mobile terminal is a cellular telephone. It is provided during the pairing with the second mobile terminal that the server 10 associates the payment instrument 17 with the second terminal, with a second terminal identifier. The personal cryptogram 21 may be identical. When the verification server receives the secure payment token 104, it performs the same cryptographic calculation as the processing agent 23 of the payment application 24. Once validated, the authorization order is transmitted with the data 30. Bank 105 of the instrument 17 associated with the token 103 to the banking entity 16 via the payment network 15.
    [0026] It will be noted that the first token 103 transmitted by the server 11 to the terminal 12 can be used for several payment transactions. Its use may be restricted for a specified period, a number of payment transactions or a transaction amount which may be the sum of several payment transactions.
    权利要求:
    Claims (15)
    [0001]
    REVENDICATIONS1. Method for securing a first token (103) derived from a payment instrument (17) from a subscriber that can be hosted in a mobile terminal (12) by a payment application (24), characterized in that it comprises the following successive steps: - pairing (36) on the one hand with an identifier (22) of the mobile terminal (12) and the payment instrument and on the other hand with a personal cryptogram (21) and the payment instrument, - the provisioning (53) of the first token (103) to the payment application (24), - the receipt (55) of data of a payment transaction by the application of payment, - the generation (57) of a second secure payment token (104) by the encryption of at least the first token (103), the transaction data, the terminal identifier (22) and the personal cryptogram (21). 20
    [0002]
    2. Method according to claim 1, characterized in that the pairing (36) is operated following a successful authentication protocol between the payment application (24) and a remote authentication server (10).
    [0003]
    3. Method according to claim 2, characterized in that the pairing (36) is performed when the payment instrument (17) is registered in the payment application (24).
    [0004]
    4. Method according to any one of the preceding claims, characterized in that the first token (103) is a random data derived from a data item (105) representing the bank account number attached to the payment instrument ( 17).
    [0005]
    5. Method according to any one of the preceding claims, characterized in that the encryption of the first token (103) is executed by means of a temporary key received from a server (11) for generating the first token (103). .
    [0006]
    6. Method according to any one of the preceding claims, characterized in that it further comprises the generation (56) of the identifier (22) of the terminal and the personal cryptogram (21) by the payment application (24). ), the generation being triggered by the receipt (55) of the data of the transaction.
    [0007]
    7. Method according to claim 6, characterized in that the generation of the identifier (22) of the terminal and the personal cryptogram (21) by the payment application (24) comprises reading in a secure memory of the terminal (12). ) subject to the entry of a personal password or the execution of a cryptographic calculation conditioned to the entry of a personal password.
    [0008]
    8. Method according to claim 6 or 7, characterized in that the generation of the identifier (22) of the terminal and the personal cryptogram (21) by the payment application (24) is triggered by a request for authentication of the subscriber during the payment transaction, the payment transaction being a contactless payment transaction in accordance with ISO / IEC 14443.
    [0009]
    9. Method according to any one of claims 6 to 8, characterized in that, during the execution of the banking transaction, the identifier (22) and the personal cryptogram (21) are stored in a volatile memory of the terminal (12). 3028639 28
    [0010]
    10. Method according to any one of the preceding claims, characterized in that the provisioning comprises the writing of the first token (103) in a non-volatile memory of the terminal (12). 5
    [0011]
    11. A mobile terminal comprising a payment application comprising a processing agent (23) of a first token (103) derived from a payment instrument (17) of a subscriber and a data receiving means of a transaction method of payment, characterized in that the payment application (24) further comprises: - a pairing means (26) of an identifier of the mobile terminal (22) and a personal cryptogram (21) with the payment instrument; and in that the first token processing agent (23) comprises means for generating a second secure payment token (104) by encrypting at least the first token (103). , the transaction data, the identifier (22) of the mobile terminal and the personal cryptogram (21).
    [0012]
    Terminal according to claim 11, characterized in that it further comprises means for generating the identifier (22) of the mobile terminal (12) and the personal encryption device (21) by the payment application (24). ).
    [0013]
    13. A first token generation server (11) comprising means for generating a first token (103) derived from a payment instrument (17) of a subscriber, characterized in that it comprises furthermore, - means for pairing an identifier (22) of the mobile terminal (12) and a personal cryptogram (21) of the subscriber with the payment instrument (17), 3028639 29 - a verification means of a second secure payment token (104) generated by the encryption of at least the first token (103), transaction data, the identifier (22) of the mobile terminal and the personal cryptogram (21).
    [0014]
    14. Server according to claim 13, characterized in that the identifier (22) of the mobile terminal and the personal cryptogram (21) of the subscriber are received from an authentication server (10). 10
    [0015]
    15. Server according to claim 13 or 14, characterized in that the first token (103) is generated by means of a random generator function of at least one datum (105) representing the bank account number attached to the instrument of payment (17).
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3221815B1|2021-05-19|Method for securing a payment token
    US9613365B2|2017-04-04|Methods, systems, and computer readable media for secure near field communication of a non-secure memory element payload
    US20180218358A1|2018-08-02|Trusted service manager | architectures and methods
    US20130041831A1|2013-02-14|Secure and shareable payment system using trusted personal device
    FR2993382A1|2014-01-17|SECURE ELECTRONIC ENTITY FOR THE AUTHORIZATION OF A TRANSACTION
    WO2014064353A1|2014-05-01|Method of providing a secured service
    WO2007006771A1|2007-01-18|Transaction authorization method and device
    EP3095223B1|2022-03-16|Method of transmitting encrypted data, method of reception, devices and computer programs corresponding thereto
    EP2053553A1|2009-04-29|Method and device for exchanging values between portable personal electronic entities
    EP2053554A1|2009-04-29|Portable electronic device for exchanging values and method of implementing such a device
    EP3588418A1|2020-01-01|Method for conducting a transaction, terminal, server and corresponding computer program
    EP3570238A1|2019-11-20|Method for conducting a transaction, terminal, server and corresponding computer program
    EP3758322A1|2020-12-30|Method and system for generating encryption keys for transaction or connection data
    EP3029878B1|2020-05-27|Method for transmitting a secret with limited lifetime for conducting a transaction between a mobile terminal and a system
    WO2016108017A1|2016-07-07|Payment request verification method including determination of the location where a payment token was issued
    Tran2020|Mobile Payment Security: A case study of Digital Wallet MOMO
    WO2016034812A1|2016-03-10|Securing of encryption keys for transactions on a device lacking a secure module
    FR3031609A1|2016-07-15|METHOD OF PROCESSING A TRANSACTION FROM A COMMUNICATION TERMINAL
    GB2525423A|2015-10-28|Secure Token implementation
    FR3008516A1|2015-01-16|TRANSACTION METHOD, TERMINAL AND CORRESPONDING COMPUTER PROGRAM.
    同族专利:
    公开号 | 公开日
    JP2017537421A|2017-12-14|
    JP6704919B2|2020-06-03|
    ES2881873T3|2021-11-30|
    WO2016079403A1|2016-05-26|
    EP3221815B1|2021-05-19|
    US20190087814A1|2019-03-21|
    EP3221815A1|2017-09-27|
    FR3028639B1|2016-12-23|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    WO2012040377A1|2010-09-21|2012-03-29|Visa International Service Association|Device enrollment system and method|
    US20140279476A1|2013-03-15|2014-09-18|Visa International Service Association|Multiple Account Dynamic Card Apparatuses, Methods and Systems|
    EP1028401A3|1999-02-12|2003-06-25|Citibank, N.A.|Method and system for performing a bankcard transaction|
    EP1490846A2|2002-04-03|2004-12-29|Swivel Secure Limited|System and method for secure credit and debit card transactions|
    US20040025039A1|2002-04-30|2004-02-05|Adam Kuenzi|Lock box security system with improved communication|
    NZ547903A|2006-06-14|2008-03-28|Fronde Anywhere Ltd|A method of generating an authentication token and a method of authenticating an online transaction|
    EP2186238A4|2007-08-31|2016-01-27|4361423 Canada Inc|Apparatus and method for conducting secure financial transactions|
    WO2013116726A1|2012-02-03|2013-08-08|Ebay Inc.|Adding card to mobile wallet using nfc|
    JP2014106593A|2012-11-26|2014-06-09|International Business Maschines Corporation|Transaction authentication method and system|
    US20160005032A1|2012-11-28|2016-01-07|Hoverkey Ltd.|Method and system of providing authentication of user access to a computer resource via a mobile device using multiple separate security factors|
    RU2019114941A|2013-10-11|2019-06-13|Виза Интернэшнл Сервис Ассосиэйшн|NETWORK TOKEN SYSTEM|
    US20160012465A1|2014-02-08|2016-01-14|Jeffrey A. Sharp|System and method for distributing, receiving, and using funds or credits and apparatus thereof|
    CN104539701B|2014-12-29|2018-04-27|飞天诚信科技股份有限公司|A kind of equipment of activation line mobile terminal token and the method for work of system|
    US9674705B2|2015-04-22|2017-06-06|Kenneth Hugh Rose|Method and system for secure peer-to-peer mobile communications|
    US10666642B2|2016-02-26|2020-05-26|Ca, Inc.|System and method for service assisted mobile pairing of password-less computer login|
    US20180150816A1|2016-11-30|2018-05-31|American Express Travel Related Services Company, Inc.|Mobile Payment System|US20170148014A1|2015-11-25|2017-05-25|Morphotrust Usa, Llc|Device-Associated Token Identity|
    WO2017091987A1|2015-12-01|2017-06-08|华为技术有限公司|Method and apparatus for secure interaction between terminals|
    EP3185194A1|2015-12-24|2017-06-28|Gemalto Sa|Method and system for enhancing the security of a transaction|
    CN111615105A|2016-07-18|2020-09-01|阿里巴巴集团控股有限公司|Information providing method, information obtaining method, information providing device, information obtaining device and terminal|
    KR102008206B1|2016-07-20|2019-08-07|코나아이 |A server, method and system for managing card transaction service|
    US10972911B2|2017-09-28|2021-04-06|Apple Inc.|Location-based credential selection for wireless transactions|
    US10956905B2|2017-10-05|2021-03-23|The Toronto-Dominion Bank|System and method of session key generation and exchange|
    US20200143381A1|2018-11-06|2020-05-07|Paypal, Inc.|System and Method for Obtaining a Temporary CVV using Tokenization Rails|
    US10936191B1|2018-12-05|2021-03-02|Pure Storage, Inc.|Access control for a computing system|
    WO2020163580A1|2019-02-06|2020-08-13|Mastercard International Incorporated|Method and system for generation of a high assurance payment token|
    法律状态:
    2015-10-23| PLFP| Fee payment|Year of fee payment: 2 |
    2016-05-20| PLSC| Publication of the preliminary search report|Effective date: 20160520 |
    2016-10-24| PLFP| Fee payment|Year of fee payment: 3 |
    2017-10-20| PLFP| Fee payment|Year of fee payment: 4 |
    2018-10-24| PLFP| Fee payment|Year of fee payment: 5 |
    2019-10-22| PLFP| Fee payment|Year of fee payment: 6 |
    2020-10-21| PLFP| Fee payment|Year of fee payment: 7 |
    2021-10-20| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1461087A|FR3028639B1|2014-11-17|2014-11-17|METHOD FOR SECURING A PAYMENT TOKEN|FR1461087A| FR3028639B1|2014-11-17|2014-11-17|METHOD FOR SECURING A PAYMENT TOKEN|
    ES15816814T| ES2881873T3|2014-11-17|2015-11-16|Procedure for the protection of a payment token|
    EP15816814.6A| EP3221815B1|2014-11-17|2015-11-16|Method for securing a payment token|
    PCT/FR2015/053079| WO2016079403A1|2014-11-17|2015-11-16|Method for securing a payment token|
    JP2017545000A| JP6704919B2|2014-11-17|2015-11-16|How to secure your payment token|
    US15/526,813| US20190087814A1|2014-11-17|2015-11-16|Method for securing a payment token|
    [返回顶部]